Enterprise architecture planning

Enterprise Architecture Planning (EAP) in Enterprise Architecture is the planning process of defining architectures for the use of information in support of the business and the plan for implementing those architectures.[2]

Contents

Overview

One of the earlier professional practitioners in the field of system architecture Steven H. Spewak in 1998 defined Enterprise Architecture Planning (EAP) as "the process of defining architectures for the use of information in support of the business and the plan for implementing those architectures." Spewak’s approach to EAP is similar to that taken by DOE in that the business mission is the primary driver. That is followed by the data required to satisfy the mission, followed by the applications that are built using that data, and finally by the technology to implement the applications.[1]

This hierarchy of activity is represented in the figure above, in which the layers are implemented in order, from top to bottom. Based on the Business Systems Planning (BSP) approach developed by John Zachman, EAP takes a data-centric approach to architecture planning to provide data quality, access to data, adaptability to changing requirements, data interoperability and sharing, and cost containment. This view counters the more traditional view that applications should be defined before data needs are determined or provided for.[1]

EAP topics

Zachman framework

EAP defines the blueprint for subsequent design and implementation and it places the planning/defining stages into a framework. It does not explain how to define the top two rows of the Zachman Framework in detail but for the sake of the planning exercise, abbreviates the analysis. The Zachman Framework provides the broad context for the description of the architecture layers, while EAP focuses on planning and managing the process of establishing the business alignment of the architectures.[2]

EAP is planning that focuses on the development of matrixes for comparing and analyzing data, applications, and technology. Most important, EAP produces an implementation plan. Within the Federal Enterprise Architecture, EAP will be completed segment enterprise by segment enterprise. The results of these efforts may be of Governmentwide value; therefore, as each segment completes EAP, the results will be published on the ArchitecturePlus web site.[2]

EAP components

Enterprise Architecture Planning model consists of four levels:

  • Business process modeling, the compilation of a knowledge base about the business functions and the information used in conducting and supporting the various business processes, and
  • Current Systems and Technology, the definition of current application systems and supporting technology platforms.
  • Data Architecture - Definition of the major kinds of data needed to support the business.
  • Applications Architecture - Definition of the major kinds of applications needed to manage that data and support the business functions.
  • Technology Architecture - Definition of the technology platforms needed to support the applications that manage the data and support the business functions.

EAP methodology

The Enterprise Architecture Planning (EAP) methodology is beneficial to understanding the further definition of the Federal Enterprise Architecture Framework at level IV. EAP is a how to approach for creating the top two rows of the Zachman Framework, Planner and Owner. The design of systems begins in the third row, outside the scope of EAP.[2]

EAP focuses on defining what data, applications, and technology architectures are appropriate for and support the overall enterprise. Exhibit 6 shows the seven components (or steps) of EAP for defining these architectures and the related migration plan. The seven components are in the shape of a wedding cake, with each layer representing a different focus of each major task (or step).[2]

Applications

Spewak approach to Federal Enterprise Architecture has helped organizations with modeling, business strategy planning, process improvement, data warehousing, and various support systems designs, data administration standards, object-oriented and information engineering methodologies, and project management.[2]

See also


References

  1. ^ a b c FAA (1998). Federal Information Architecture Initiatives Federal Aviation Administration, February 1998.
  2. ^ a b c d e f g h i j The Chief Information Officers Council (1999). Federal Enterprise Architecture Framework Version 1.1 September 1999.

Further reading